Small Change List

CLをSmallにすべき理由:

5分のレビュー時間を何度かとる方が30分のレビュー時間をとるよりも容易

より完全にレビューできる、見落としがなくなる

バグを入れにくくなる

コンフリクトしづらくなる

きれいにしやすい

レビューでブロックされる時間が短くなる。→コンフリクトを減らすことにもつながる

ロールバックがシンプルになる→これはよくわからない

Smallであるとはどういうことか

大きなCLでもいいのはどういう時か

削除は一行分の変更と考えても差し支えないことが多い

リファクタリングを分割する

クラスの移動とリネームをするCLとそのクラスのバグを修正するCLは分ける

ローカル変数のリネームくらいだったらバグ修正CLと同じでもいいかもしれない

関連するテストコードは同一のCLに含める

ロジックの追加や変更を含むCLは、その新しい振る舞いに対するアップデートされたテストを含むべきである

ビルドを壊さないこと